<html>
<head><meta charset="utf-8"><title>Can we make more `const unsafe` now? · t-compiler/const-eval · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/index.html">t-compiler/const-eval</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html">Can we make more `const unsafe` now?</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="245391734"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245391734" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245391734">(Jul 09 2021 at 01:44)</a>:</h4>
<p>So, IIRC <span class="user-mention" data-user-id="120791">@RalfJ</span>'s proposal for how to handle UB in <code>const fn</code> was accepted. Does that mean we can start carefully making certain unsafe functions <code>const</code> now?</p>
<p>In particular, I have some interest in <code>slice get_unchecked</code> (I have a "fast and non-const" and "slow and const" version of a certain function...</p>



<a name="245413621"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245413621" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245413621">(Jul 09 2021 at 08:11)</a>:</h4>
<p>Yes. In fact, a big one is already on its way: <a href="https://github.com/rust-lang/rust/pull/85769">https://github.com/rust-lang/rust/pull/85769</a></p>



<a name="245413639"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245413639" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245413639">(Jul 09 2021 at 08:11)</a>:</h4>
<p>I'd say wait until that lands</p>



<a name="245413645"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245413645" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245413645">(Jul 09 2021 at 08:11)</a>:</h4>
<p>and then open the floodgates ;)</p>



<a name="245413816"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245413816" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245413816">(Jul 09 2021 at 08:13)</a>:</h4>
<p>FWIW I am actually a bit surprised that the lang team isn't discussing this a bit more</p>
<blockquote>
<p>However, this will still let us write code like</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="k">pub</span><span class="w"> </span><span class="k">const</span><span class="w"> </span><span class="k">unsafe</span><span class="w"> </span><span class="k">fn</span> <span class="nf">random</span><span class="p">()</span><span class="w"> </span>-&gt; <span class="kt">usize</span> <span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="kd">let</span><span class="w"> </span><span class="n">a</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">5</span><span class="p">;</span><span class="w"></span>
<span class="w">    </span><span class="n">std</span>::<span class="n">mem</span>::<span class="n">transmute</span><span class="p">(</span><span class="o">&amp;</span><span class="n">a</span><span class="p">)</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>
<p>which would be the first stable const fn that is not guaranteed to behave deterministically at run-time.<br>
This function certainly has UB when called at compile-time, but whether it has UB when called at run-time <a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/286">is unclear</a>.</p>
</blockquote>



<a name="245413822"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245413822" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245413822">(Jul 09 2021 at 08:13)</a>:</h4>
<p>but I guess I won't complain^^</p>



<a name="245437631"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245437631" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> oli <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245437631">(Jul 09 2021 at 12:45)</a>:</h4>
<p><span class="user-mention silent" data-user-id="120791">RalfJ</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F/near/245413645">said</a>:</p>
<blockquote>
<p>and then open the floodgates <span aria-label="wink" class="emoji emoji-1f609" role="img" title="wink">:wink:</span></p>
</blockquote>
<p>I believe all future unsafe const fn are in T-libs territory as long as wg-const-eval also has a look</p>



<a name="245438343"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245438343" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jacob Pratt <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245438343">(Jul 09 2021 at 12:51)</a>:</h4>
<p>Keep in mind for any future PRs that const panic isn't yet stable, so we don't want to give people an escape hatch that's quite dangerous. That's why <code>unreachable_unchecked</code> hasn't yet been made const stably.</p>



<a name="245464342"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245464342" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245464342">(Jul 09 2021 at 16:22)</a>:</h4>
<p><span class="user-mention" data-user-id="120791">@RalfJ</span> Honestly, I think we're not discussing it more because you already had a very clear pitch for how we should handle UB in const evaluation and that's exactly what we want to use.</p>



<a name="245465327"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245465327" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245465327">(Jul 09 2021 at 16:30)</a>:</h4>
<p><span class="user-mention" data-user-id="239881">@Josh Triplett</span> it's not the const UB this is about</p>



<a name="245465448"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245465448" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245465448">(Jul 09 2021 at 16:31)</a>:</h4>
<p>in current stable Rust, when I tell you that some function is declared as <code>const fn() -&gt; usize</code>, you know that when you call this function <em>at runtime</em>, multiple times, it will always produce the same result.</p>



<a name="245465493"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245465493" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245465493">(Jul 09 2021 at 16:31)</a>:</h4>
<p>if we stabilize <code>const_fn_transmute</code> or <code>const_fn_union</code>, we lose that property.</p>



<a name="245465557"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245465557" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245465557">(Jul 09 2021 at 16:32)</a>:</h4>
<p>note that const UB has nothing to do with it, so no amount of handling (or not handling) UB during const evaluation will change anything about this</p>



<a name="245465589"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245465589" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245465589">(Jul 09 2021 at 16:32)</a>:</h4>
<p>But it isn't <code>const fn</code>, it's <code>const unsafe fn</code>. :)</p>



<a name="245465635"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245465635" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245465635">(Jul 09 2021 at 16:32)</a>:</h4>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="k">pub</span><span class="w"> </span><span class="k">const</span><span class="w"> </span><span class="k">fn</span> <span class="nf">nondet</span><span class="p">()</span><span class="w"> </span>-&gt; <span class="kt">usize</span> <span class="p">{</span><span class="w"> </span><span class="k">unsafe</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="kd">let</span><span class="w"> </span><span class="n">a</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">5</span><span class="p">;</span><span class="w"></span>
<span class="w">    </span><span class="n">std</span>::<span class="n">mem</span>::<span class="n">transmute</span><span class="p">(</span><span class="o">&amp;</span><span class="n">a</span><span class="p">)</span><span class="w"></span>
<span class="p">}</span><span class="w"> </span><span class="p">}</span><span class="w"></span>
</code></pre></div>



<a name="245465650"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245465650" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245465650">(Jul 09 2021 at 16:33)</a>:</h4>
<p>not sure why that would make any difference^^</p>



<a name="245465695"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245465695" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245465695">(Jul 09 2021 at 16:33)</a>:</h4>
<p>(I was half joking, though in general I do think it's relevant that you can't get such behavior without unsafe.)</p>



<a name="245465840"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245465840" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245465840">(Jul 09 2021 at 16:34)</a>:</h4>
<p>the entire point of <code>unsafe</code> is that it can be safely encapsulated :)</p>



<a name="245465969"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245465969" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245465969">(Jul 09 2021 at 16:35)</a>:</h4>
<p>I do wonder if it would make sense to catch at compile time cases where a const function depends on something non-deterministic like a stack address.</p>



<a name="245465971"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245465971" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245465971">(Jul 09 2021 at 16:35)</a>:</h4>
<p>and yes this function is UB to call at compiletime</p>



<a name="245466002"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466002" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466002">(Jul 09 2021 at 16:35)</a>:</h4>
<p>but it's (maybe) not UB to call at runtime</p>



<a name="245466054"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466054" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466054">(Jul 09 2021 at 16:36)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F/near/245465969">said</a>:</p>
<blockquote>
<p>I do wonder if it would make sense to catch at compile time cases where a const function depends on something non-deterministic like a stack address.</p>
</blockquote>
<p>we could make an effort but it'll never catch all cases</p>



<a name="245466059"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466059" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466059">(Jul 09 2021 at 16:36)</a>:</h4>
<p>so that is a separate discussion</p>



<a name="245466087"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466087" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466087">(Jul 09 2021 at 16:36)</a>:</h4>
<p>I'm only interested in ironclad guarantees here, which we'll never achieve with such a check</p>



<a name="245466107"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466107" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466107">(Jul 09 2021 at 16:36)</a>:</h4>
<p>Is it just UB at compile time because it returns an address and const evaluation carefully makes a distinction between addresses and numbers?</p>



<a name="245466134"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466134" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466134">(Jul 09 2021 at 16:37)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F/near/245466107">said</a>:</p>
<blockquote>
<p>Is it just UB at compile time because it returns an address and const evaluation carefully makes a distinction between addresses and numbers?</p>
</blockquote>
<p>"just" is doing a lot of work here :)</p>



<a name="245466165"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466165" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466165">(Jul 09 2021 at 16:37)</a>:</h4>
<p>yes, <a href="https://github.com/rust-lang/rust/issues/85769">#85769</a> documents that it is UB during const-eval to transmute ptrs to ints</p>



<a name="245466179"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466179" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466179">(Jul 09 2021 at 16:37)</a>:</h4>
<p>"just" here meaning that there isn't any other reason why it's UB, such as something magic involving pointer provenance.</p>



<a name="245466212"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466212" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466212">(Jul 09 2021 at 16:38)</a>:</h4>
<p>the distinction between pointers and numbers <em>is</em> pointer provenance</p>



<a name="245466294"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466294" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466294">(Jul 09 2021 at 16:38)</a>:</h4>
<p>(avoiding the term "address" here as I usually use that for the part of the pointer without the provenance)</p>



<a name="245466316"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466316" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466316">(Jul 09 2021 at 16:38)</a>:</h4>
<p>It seems like, at compile time, the distinction is more clear than that.</p>



<a name="245466351"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466351" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466351">(Jul 09 2021 at 16:39)</a>:</h4>
<p>well, at compile-time, provenance is non-optional</p>



<a name="245466387"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466387" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466387">(Jul 09 2021 at 16:39)</a>:</h4>
<p>Insofar as the compiler is synthesizing locations for use by operations that think they're using memory, but by the end of the operation they need to not be using memory.</p>



<a name="245466388"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466388" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466388">(Jul 09 2021 at 16:39)</a>:</h4>
<p>for runtime a provenance-free model is at least conceivable (it's just not matching reality)</p>



<a name="245466418"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466418" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466418">(Jul 09 2021 at 16:39)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F/near/245466387">said</a>:</p>
<blockquote>
<p>Insofar as the compiler is synthesizing locations for use by operations that think they're using memory, but by the end of the operation they need to not be using memory.</p>
</blockquote>
<p>no that's not the reason</p>



<a name="245466419"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466419" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466419">(Jul 09 2021 at 16:39)</a>:</h4>
<p>s/reality/LLVM/ :)</p>



<a name="245466445"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466445" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466445">(Jul 09 2021 at 16:39)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F/near/245466419">said</a>:</p>
<blockquote>
<p>s/reality/LLVM/ :)</p>
</blockquote>
<p>s/reality/LLVM+GCC+MSVC+ICC+.../<br>
;)</p>



<a name="245466527"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466527" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466527">(Jul 09 2021 at 16:40)</a>:</h4>
<p>oh and CompCert, too, of course</p>



<a name="245466560"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466560" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466560">(Jul 09 2021 at 16:40)</a>:</h4>
<p>the reason provenance is non-optional at compile time is that we dont knoow the physical base addresses yet</p>



<a name="245466589"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466589" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466589">(Jul 09 2021 at 16:40)</a>:</h4>
<p>so we have to emit relocations to LLVM, in case the final const value contains pointers</p>



<a name="245466612"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466612" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466612">(Jul 09 2021 at 16:41)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F/near/245466387">said</a>:</p>
<blockquote>
<p>Insofar as the compiler is synthesizing locations for use by operations that think they're using memory, but by the end of the operation they need to not be using memory.</p>
</blockquote>
<p>this ^ is just saying "programs run in an interpreter". that makes no difference.</p>



<a name="245466644"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466644" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466644">(Jul 09 2021 at 16:41)</a>:</h4>
<p>"don't know the physical base addresses" is what I was trying to describe when I said "synthesizing locations".</p>



<a name="245466731"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466731" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466731">(Jul 09 2021 at 16:42)</a>:</h4>
<p>oh okay. then I dont get the "need to not be using memory" part.</p>



<a name="245466735"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466735" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466735">(Jul 09 2021 at 16:42)</a>:</h4>
<p>(also, I didn't realize we handled ending up with a pointer yet)</p>



<a name="245466782"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466782" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466782">(Jul 09 2021 at 16:42)</a>:</h4>
<p>(oh we handle that since forever)</p>



<a name="245466798"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466798" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466798">(Jul 09 2021 at 16:42)</a>:</h4>
<p>I didn't know that; that's awesome. I had thought that was still a work in progress.</p>



<a name="245466844"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466844" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466844">(Jul 09 2021 at 16:43)</a>:</h4>
<p>the CTFE engine is capable of running <em>enormous</em> amounts of Rust code already. like, almost as much as Miri-the-tool.</p>



<a name="245466858"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466858" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466858">(Jul 09 2021 at 16:43)</a>:</h4>
<p>Am I misunderstanding something? I thought that was the primary issue with being able to handle something like Vec or Box in const eval?</p>



<a name="245466879"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466879" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466879">(Jul 09 2021 at 16:43)</a>:</h4>
<p>the "only" thing that's missing is figuring out static checks that ensure this enormously powerful engine doesnt break everything ;)</p>



<a name="245466974"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245466974" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245466974">(Jul 09 2021 at 16:44)</a>:</h4>
<p>no, the issues around Vec and Box are all about how to make this <em>safe</em></p>



<a name="245467073"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245467073" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245467073">(Jul 09 2021 at 16:45)</a>:</h4>
<p>but we should probably not talk about const heap stuff here, that's a mostly separate discussion :)</p>



<a name="245467214"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245467214" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245467214">(Jul 09 2021 at 16:46)</a>:</h4>
<p>what we have on stable is things like</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="k">static</span><span class="w"> </span><span class="n">FOO</span>: <span class="p">(</span><span class="o">&amp;</span><span class="kt">i32</span><span class="p">,</span><span class="w"> </span><span class="o">&amp;</span><span class="kt">i32</span><span class="p">)</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">(</span><span class="o">&amp;</span><span class="mi">4</span><span class="p">,</span><span class="w"> </span><span class="o">&amp;</span><span class="mi">4</span><span class="p">);</span><span class="w"></span>
</code></pre></div>
<p>that also involves pointers in the final value</p>



<a name="245467994"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245467994" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245467994">(Jul 09 2021 at 16:53)</a>:</h4>
<p>Got it. Thanks for that explanation; I had been misunderstanding the issue.</p>



<a name="245468116"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245468116" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245468116">(Jul 09 2021 at 16:54)</a>:</h4>
<p>I think the distinction between "this isn't possible yet" and "this isn't possible to make safe for stable" was not always clear to me, and sometimes got conflated.</p>



<a name="245470365"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245470365" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245470365">(Jul 09 2021 at 17:10)</a>:</h4>
<p>so, back to the original topic...</p>
<blockquote>
<p>in current stable Rust, when I tell you that some function is declared as <code>const fn() -&gt; usize</code>, you know that when you call this function <em>at runtime</em>, multiple times, it will always produce the same result.</p>
</blockquote>
<p>This is not a guarantee that we ever explicitly designed, but just "fell out" of the const checks, and we made sure to maintain it so far. I know Centril had plans for this, using <code>const</code> as a kind of "pure" annotation in Rust.  I am personally not sold on that (effect systems are tricky, const is tricky, we'd make our life a lot harder by mixing them), but it is certainly an interesting idea and I want to be sure that the entire lang team is aware and onboard with what happens. I want to avoid that in 2 years we're like "oh no if only we had known back then what we are throwing away".<br>
(this also pertains to the <code>const_fn_float</code> discussion -- floats are usually not outright non-deterministic, but at least certain NaN payloads can actually differ between when the NaN is created at compiletime vs runtime, and also Wasm explicitly specifies many NaN payloads as non-deterministic and who knows, there might be implementations exploiting that.)</p>



<a name="245470630"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245470630" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245470630">(Jul 09 2021 at 17:12)</a>:</h4>
<p>Arguably, a <em>safe</em> such <code>const fn</code> is "unsound" because it has const-UB, and we could use that as our holding ground. That might be enough, for now, but won't help with the NaN problem.</p>



<a name="245471246"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245471246" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245471246">(Jul 09 2021 at 17:17)</a>:</h4>
<p>I know that GCC has a lot of code trying to make sure it can evaluate floats and similar at compile time and produce exactly the same result it would get at runtime. I don't know how well it succeeds, but I know it tries.</p>



<a name="245471423"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245471423" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245471423">(Jul 09 2021 at 17:18)</a>:</h4>
<p>I think arguing edge case definitions doesn't make for a good public image.</p>
<p>And you can the problem with all safe code:</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="k">const</span><span class="w"> </span><span class="k">fn</span> <span class="nf">nondet_as</span><span class="p">()</span><span class="w"> </span>-&gt; <span class="kt">usize</span> <span class="p">{</span><span class="w"></span>
<span class="w">  </span><span class="kd">let</span><span class="w"> </span><span class="n">x</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">0</span><span class="p">;</span><span class="w"></span>
<span class="w">  </span><span class="o">&amp;</span><span class="n">x</span><span class="w"> </span><span class="k">as</span><span class="w"> </span><span class="o">*</span><span class="k">const</span><span class="w"> </span><span class="kt">i32</span><span class="w"> </span><span class="k">as</span><span class="w"> </span><span class="kt">usize</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>



<a name="245471479"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245471479" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245471479">(Jul 09 2021 at 17:19)</a>:</h4>
<p>(is that legal code today in stable?)</p>



<a name="245471532"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245471532" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245471532">(Jul 09 2021 at 17:20)</a>:</h4>
<p>no it's not</p>



<a name="245471621"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245471621" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245471621">(Jul 09 2021 at 17:20)</a>:</h4>
<p>but it's the same "pointer becomes an integer" problem, and it's safe as non-const, and it would confuse countless people to say it's unsafe or even unsound but only if in const fn</p>



<a name="245471665"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245471665" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245471665">(Jul 09 2021 at 17:21)</a>:</h4>
<p>Regarding the original question, I'm curious to what degree we could reliably detect the returning of non-deterministic addresses in a const fn. What's the simplest example we can produce that is definitely not reasonable to detect?</p>



<a name="245471874"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245471874" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245471874">(Jul 09 2021 at 17:23)</a>:</h4>
<p>I think you have to use <code>as</code> or <em>some form</em> of transmutation to get an int from a pointer, but you can be pretty devilish with the transmutation and so you'd probably be able to sidestep the check if you were determined.</p>



<a name="245473206"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245473206" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245473206">(Jul 09 2021 at 17:33)</a>:</h4>
<p><span class="user-mention silent" data-user-id="224471">Lokathor</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F/near/245471621">said</a>:</p>
<blockquote>
<p>but it's the same "pointer becomes an integer" problem, and it's safe as non-const, and it would confuse countless people to say it's unsafe or even unsound but only if in const fn</p>
</blockquote>
<p>my plan is to never allow ptr-to-int casts in <code>const fn</code></p>



<a name="245473223"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245473223" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245473223">(Jul 09 2021 at 17:33)</a>:</h4>
<p>not safely, not unsafely, just not at all -- as you said, it's <em>safe</em> during non-const, so making it "weird" during const is probably a bad idea. that leaves making it impossible during const the only option.</p>



<a name="245473233"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245473233" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245473233">(Jul 09 2021 at 17:33)</a>:</h4>
<p>so I think we got that case covered</p>



<a name="245473360"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245473360" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245473360">(Jul 09 2021 at 17:34)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F/near/245471665">said</a>:</p>
<blockquote>
<p>Regarding the original question, I'm curious to what degree we could reliably detect the returning of non-deterministic addresses in a const fn. What's the simplest example we can produce that is definitely not reasonable to detect?</p>
</blockquote>
<p>are you asking for the simplest example of the halting problem? because that's what it sounds like. ;)</p>



<a name="245473578"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245473578" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245473578">(Jul 09 2021 at 17:37)</a>:</h4>
<blockquote>
<p>I think arguing edge case definitions doesn't make for a good public image.</p>
</blockquote>
<p>"public image"? we're doing PL design here, not PR...<br>
and anyway, arguing edge cases is exactly how Rust got its good public image -- "memory safety" is a game that consists almost entirely of arguing edge cases; "soundness" even more so.</p>



<a name="245473860"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245473860" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245473860">(Jul 09 2021 at 17:39)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F/near/245471246">said</a>:</p>
<blockquote>
<p>I know that GCC has a lot of code trying to make sure it can evaluate floats and similar at compile time and produce exactly the same result it would get at runtime. I don't know how well it succeeds, but I know it tries.</p>
</blockquote>
<p>yeah and so does LLVM and eddyb ported that code to Rust and that's what we use in CTFE.<br>
but some platforms have weird behavior for which bit patterns they use for a NaN (and of course x87 is just ridicolous), so it is my understanding that <em>guaranteeing</em> that we match the runtime bit patterns is unrealistic. Wasm gave up and made it non-deterministic. Wasm is extremely good at what it does, I doubt we can do better.</p>



<a name="245475049"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245475049" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245475049">(Jul 09 2021 at 17:47)</a>:</h4>
<p>IEEE should've just forced exact bitpatterns on everyone :(</p>



<a name="245475074"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245475074" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245475074">(Jul 09 2021 at 17:47)</a>:</h4>
<p>I will never stop being mad about it</p>



<a name="245475159"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245475159" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245475159">(Jul 09 2021 at 17:48)</a>:</h4>
<p>not only is it entirely plausible, it would've forced vendors to cut less corners</p>



<a name="245475271"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245475271" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245475271">(Jul 09 2021 at 17:49)</a>:</h4>
<p><span class="user-mention" data-user-id="120791">@RalfJ</span> I have no problem writing off the x87. :)</p>



<a name="245475395"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245475395" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245475395">(Jul 09 2021 at 17:50)</a>:</h4>
<p><span class="user-mention" data-user-id="120791">@RalfJ</span> I would ideally like to allow pointer to int and int to pointer casts in const evaluation, as long as whenever you end up dereferencing a pointer, it's actually a valid pointer that you originally got from the const evaluation engine.</p>



<a name="245475430"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245475430" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245475430">(Jul 09 2021 at 17:50)</a>:</h4>
<p>does the i686 target use SSE2? even then, I believe we support targets where hardfloat=x87</p>



<a name="245475546"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245475546" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245475546">(Jul 09 2021 at 17:51)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F/near/245475395">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="120791">RalfJ</span> I would ideally like to allow pointer to int and int to pointer casts in const evaluation, as long as whenever you end up dereferencing a pointer, it's actually a valid pointer that you originally got from the const evaluation engine.</p>
</blockquote>
<p>isn't the reason pointer -&gt; int casts get brought up that people want to modify it as an integer, and observe address bits?</p>



<a name="245475637"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245475637" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245475637">(Jul 09 2021 at 17:52)</a>:</h4>
<p>things like having an alignment of 4 bytes and packing something else in the lowest 2 bits</p>



<a name="245475642"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245475642" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245475642">(Jul 09 2021 at 17:52)</a>:</h4>
<p><span class="user-mention" data-user-id="120791">@RalfJ</span> Also, no, I'm not asking for an example of the halting problem, I'm specifically asking about cases where we can't prove that the function <em>doesn't</em> do non-deterministic things with pointer values. We are allowed to reject valid programs. So I'm wondering if there's a line we can draw that's practically useful.</p>



<a name="245475646"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245475646" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245475646">(Jul 09 2021 at 17:52)</a>:</h4>
<p>(or more complicated things)</p>



<a name="245475723"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245475723" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245475723">(Jul 09 2021 at 17:53)</a>:</h4>
<p><span class="user-mention" data-user-id="119009">@eddyb</span> Yes, exactly. I don't think that's unreasonable at compile time any more than it is at runtime. Const evaluation should just give you an error if you ever try to dereference a pointer it didn't hand you.</p>



<a name="245475771"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245475771" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245475771">(Jul 09 2021 at 17:53)</a>:</h4>
<p>So if you want to cast a pointer to an end, stuff extra information into the zero bits, then later mask off those bits and dereference the resulting valid pointer, that seems just as reasonable at compile time as it does at runtime.</p>



<a name="245475949"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245475949" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245475949">(Jul 09 2021 at 17:55)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F/near/245475642">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="120791">RalfJ</span> Also, no, I'm not asking for an example of the halting problem, I'm specifically asking about cases where we can't prove that the function <em>doesn't</em> do non-deterministic things with pointer values. We are allowed to reject valid programs. So I'm wondering if there's a line we can draw that's practically useful.</p>
</blockquote>
<p>I guess of the problem is you don't know where pointers are. if you did, you could do conservative taint tracking with dataflow. but doing all of this symbolically wrt memory layout (because of generics) seems hard</p>



<a name="245476012"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245476012" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245476012">(Jul 09 2021 at 17:55)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F/near/245475723">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="119009">eddyb</span> Yes, exactly. I don't think that's unreasonable at compile time any more than it is at runtime. Const evaluation should just give you an error if you ever try to dereference a pointer it didn't hand you.</p>
</blockquote>
<p>why is "dereference" the problem? you can't give the user a real integer, because no possible value you come up with could be guaranteed to be a valid <em>runtime</em> pointer</p>



<a name="245476094"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245476094" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245476094">(Jul 09 2021 at 17:56)</a>:</h4>
<p>you can only at most operate on it symbolically</p>



<a name="245476231"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245476231" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245476231">(Jul 09 2021 at 17:57)</a>:</h4>
<p>(IIRC miri used to have, or maybe still does, code to do bitwise/arithmetic operations on <code>abstract base (aligned to N) + known offset</code> pointer values when it was possible to adjust the offset, i.e. the operation was compatible with the value of <code>N</code>)</p>



<a name="245476811"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245476811" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245476811">(Jul 09 2021 at 18:01)</a>:</h4>
<p><span class="user-mention" data-user-id="239881">@Josh Triplett</span> apologies if I'm reiterating previous examples, but this is what I'm thinking of:</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="k">static</span><span class="w"> </span><span class="n">ADDR</span>: <span class="kt">usize</span> <span class="o">=</span><span class="w"> </span><span class="p">(</span><span class="o">&amp;</span><span class="mi">123</span><span class="k">u8</span><span class="w"> </span><span class="k">as</span><span class="w"> </span><span class="o">*</span><span class="k">const</span><span class="w"> </span><span class="kt">u8</span><span class="w"> </span><span class="k">as</span><span class="w"> </span><span class="kt">usize</span><span class="p">)</span><span class="w"> </span><span class="o">^</span><span class="w"> </span><span class="mh">0xdeadbeef</span><span class="p">;</span><span class="w"></span>
<span class="k">fn</span> <span class="nf">main</span><span class="p">()</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="fm">dbg!</span><span class="p">(</span><span class="k">unsafe</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="o">*</span><span class="p">((</span><span class="n">ADDR</span><span class="w"> </span><span class="o">^</span><span class="w"> </span><span class="mh">0xdeadbeef</span><span class="p">)</span><span class="w"> </span><span class="k">as</span><span class="w"> </span><span class="o">*</span><span class="k">const</span><span class="w"> </span><span class="kt">u8</span><span class="p">)</span><span class="w"> </span><span class="p">});</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>



<a name="245476942"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245476942" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245476942">(Jul 09 2021 at 18:02)</a>:</h4>
<p>I don't even believe it's possible to ask a linker to handle a relocation like that for you</p>



<a name="245477201"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245477201" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245477201">(Jul 09 2021 at 18:05)</a>:</h4>
<p>Something akin to taint tracking was exactly what I had in mind: effectively, symbolic evaluation on pointers such that the actual base pointer you're operating on is recorded as part of the calculation.</p>



<a name="245477261"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245477261" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245477261">(Jul 09 2021 at 18:05)</a>:</h4>
<p>And if you ever try to do a conditional on the exact value, or something we can't determine from the alignment alone, we stop and complain.</p>



<a name="245477298"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245477298" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245477298">(Jul 09 2021 at 18:05)</a>:</h4>
<p>ah but that's the current state</p>



<a name="245477370"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245477370" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245477370">(Jul 09 2021 at 18:06)</a>:</h4>
<p>Well, that's exactly the state I was hoping for with respect to allowing pointer to integer and integer to pointer casts. :)</p>



<a name="245477415"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245477415" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245477415">(Jul 09 2021 at 18:06)</a>:</h4>
<p>so I'm confused as to what is being suggested. you can totally have an <code>usize</code> that contains an <em>abstract</em> pointer, in CTFE miri, today, AFAIK. it's just not <em>a concrete integer value</em></p>



<a name="245477489"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245477489" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245477489">(Jul 09 2021 at 18:07)</a>:</h4>
<p>This was in response to Ralf suggesting that he'd rather not allow pointer to integer casts in CTFE at all.</p>



<a name="245477637"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245477637" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245477637">(Jul 09 2021 at 18:08)</a>:</h4>
<p>ahhh. I doubt that covers everything, but that makes more sense now, thanks</p>



<a name="245477645"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245477645" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245477645">(Jul 09 2021 at 18:08)</a>:</h4>
<p>(In theory, we might be able to do better regarding exact integer values if we had better linker integration, but I'm going to ignore that possibility for now.)</p>



<a name="245477685"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245477685" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245477685">(Jul 09 2021 at 18:08)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F/near/245477201">said</a>:</p>
<blockquote>
<p>Something akin to taint tracking was exactly what I had in mind: effectively, symbolic evaluation on pointers such that the actual base pointer you're operating on is recorded as part of the calculation.</p>
</blockquote>
<p>just to clear up a bit my own mention of taint tracking: I was talking about a (conservative) static analysis, as opposed to dynamic tracking during CTFE. since the problem is <em>non-CTFE</em> use of a <code>const fn</code></p>



<a name="245477756"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245477756" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245477756">(Jul 09 2021 at 18:09)</a>:</h4>
<p>I have no problem with the idea that we track abstract pointers even when they're in an integer type, and in the end, if what you come up with can be handled with relocation then we do that, or if it can't then we complain that we can't generate code. If you generate an arbitrary swizzled pointer that the linker can't handle, and we can't figure out a way to generate what you asked for, we could just refuse.</p>



<a name="245477904"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245477904" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245477904">(Jul 09 2021 at 18:10)</a>:</h4>
<p>right, that's the state today, the value (bits vs abstract pointer) and the type are independent, but various operations (possibly even just passing the value around) only support some combinations of values and types</p>



<a name="245477918"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245477918" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245477918">(Jul 09 2021 at 18:10)</a>:</h4>
<p><span class="user-mention" data-user-id="119009">@eddyb</span> I'm wondering to what extent we could do symbolic evaluation on a const function for the purposes of evaluating whether it misbehaves at runtime. In particular, I'm wondering if we might be able to allow the vast majority of things people want to do while still actually prohibiting non-determinism.</p>



<a name="245477979"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245477979" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245477979">(Jul 09 2021 at 18:11)</a>:</h4>
<p>you'd have to pick monomorphizations to that on, that's one of the things I was alluding to</p>



<a name="245477992"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245477992" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245477992">(Jul 09 2021 at 18:11)</a>:</h4>
<p>Fair point.</p>



<a name="245478067"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245478067" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245478067">(Jul 09 2021 at 18:12)</a>:</h4>
<p>Though, in theory, we know all the monomorphizations at compile time, right?</p>



<a name="245478135"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245478135" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245478135">(Jul 09 2021 at 18:12)</a>:</h4>
<p>doing it generically is harder, because you have to treat things like ADTs symbolically, which miri pretty much does the opposite of (i.e. it handles flat memory, and only abstract pointers are symbolic)</p>



<a name="245478183"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245478183" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245478183">(Jul 09 2021 at 18:13)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F/near/245478067">said</a>:</p>
<blockquote>
<p>Though, in theory, we know all the monomorphizations at compile time, right?</p>
</blockquote>
<p>the definition would compile until you call it from runtime, which could happen in a different crate</p>



<a name="245478369"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245478369" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245478369">(Jul 09 2021 at 18:14)</a>:</h4>
<p>in general I'm strongly against so-called "post-monomorphization errors"</p>



<a name="245478590"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245478590" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245478590">(Jul 09 2021 at 18:16)</a>:</h4>
<p>When you say "harder", what scale are we on? Do you mean that such abstract evaluation is something we could do but it'd be a pain, or are we in "someone needs to do a dissertation or two on how to do that" territory? :)</p>



<a name="245478748"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245478748" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245478748">(Jul 09 2021 at 18:18)</a>:</h4>
<p>miri had that approach before it had the flat memory, so I can link you to the report which I believe compares the two to some extent</p>



<a name="245478833"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245478833" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245478833">(Jul 09 2021 at 18:18)</a>:</h4>
<p><a href="https://github.com/rust-lang/miri#history">https://github.com/rust-lang/miri#history</a> -&gt; <a href="https://solson.me/miri-report.pdf">https://solson.me/miri-report.pdf</a></p>



<a name="245479046"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245479046" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245479046">(Jul 09 2021 at 18:20)</a>:</h4>
<p>anyway I <em>personally</em> don't think it's that useful to force <code>const fn</code>s to promise anything about runtime behavior predictability, but I'm not against preventing the more egregious issues, if it's not too difficult I suppose</p>



<a name="245479161"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245479161" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245479161">(Jul 09 2021 at 18:21)</a>:</h4>
<p><span class="user-mention silent" data-user-id="224471">Lokathor</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F/near/245471423">said</a>:</p>
<blockquote>
<p>I think arguing edge case definitions doesn't make for a good public image.</p>
<p>And you can the problem with all safe code:</p>
<p><div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="k">const</span><span class="w"> </span><span class="k">fn</span> <span class="nf">nondet_as</span><span class="p">()</span><span class="w"> </span>-&gt; <span class="kt">usize</span> <span class="p">{</span><span class="w"></span>
<span class="w">  </span><span class="kd">let</span><span class="w"> </span><span class="n">x</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">0</span><span class="p">;</span><span class="w"></span>
<span class="w">  </span><span class="o">&amp;</span><span class="n">x</span><span class="w"> </span><span class="k">as</span><span class="w"> </span><span class="o">*</span><span class="k">const</span><span class="w"> </span><span class="kt">i32</span><span class="w"> </span><span class="k">as</span><span class="w"> </span><span class="kt">usize</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div><br>
</p>
</blockquote>
<p>we could catch this as "escaping pointer to local", I guess, but a big problem is not being able to know about "laundering gadgets"</p>



<a name="245479336"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245479336" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245479336">(Jul 09 2021 at 18:23)</a>:</h4>
<p>if you have a separate function that you pass the address of one of your locals to, how do you prevent it returning that address back to you? you have to also look at <em>its body</em></p>



<a name="245479627"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245479627" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245479627">(Jul 09 2021 at 18:25)</a>:</h4>
<p>I guess this is why <span class="user-mention" data-user-id="120791">@RalfJ</span> brought up the halting problem, since that's what you run into if you try to make this perfect. sadly it still applies to more restricted analyses, and I'm worried anything we could pull off would be too limited for real-world code</p>



<a name="245479644"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245479644" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245479644">(Jul 09 2021 at 18:25)</a>:</h4>
<p>code that passes around references <em>everywhere</em></p>



<a name="245479751"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245479751" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eddyb <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245479751">(Jul 09 2021 at 18:26)</a>:</h4>
<p>anyway, I gotta take off for the weekend, sorry if I forget to follow up on this</p>



<a name="245480614"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245480614" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245480614">(Jul 09 2021 at 18:33)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F/near/245475395">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="120791">RalfJ</span> I would ideally like to allow pointer to int and int to pointer casts in const evaluation, as long as whenever you end up dereferencing a pointer, it's actually a valid pointer that you originally got from the const evaluation engine.</p>
</blockquote>
<p>I think this is extremely unlikely to happen. like, even if we allowed ptr-to-int cast, doing any int operation on the result would be UB since it's not actually an integer. we could accumulate an increasing amount of hacks to permit a small subset of those operations, but this doesnt scale and just results in accumulating more and more complex code to handle an increasing amount of corner cases -- Miri used to do that, and I concluded it's a bad idea. Miri nowadays just picks proper integer base addresses for allocations. CTFE can't do that. I think the only sustainable option here is to disallow ptr-int-casts in CTFE entirely.<br>
actually needing ptr-int-casts is extremely rare, so I don't think this is a big loss.</p>



<a name="245480756"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245480756" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245480756">(Jul 09 2021 at 18:34)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F/near/245475771">said</a>:</p>
<blockquote>
<p>So if you want to cast a pointer to an end, stuff extra information into the zero bits, then later mask off those bits and dereference the resulting valid pointer, that seems just as reasonable at compile time as it does at runtime.</p>
</blockquote>
<p>to me, it really doesn't.^^ (or, well, maybe it does, but only insofar as I think this is a rather unreasonable thing to do even at runtime. ;) to wit: all the "fun" we are having due to provenance. there <em>is</em> a very reasonable way to do ptr-int-roundtrips at runtime, but sadly that's not what C did so here we are...)<br>
if we want to support something like this, I'd much rather add const intrinsics to directly manipulate the low bits of a ptr value, than support ptr-int-casts.</p>



<a name="245480841"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245480841" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245480841">(Jul 09 2021 at 18:35)</a>:</h4>
<p><span class="user-mention silent" data-user-id="119009">eddyb</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F/near/245476231">said</a>:</p>
<blockquote>
<p>(IIRC miri used to have, or maybe still does, code to do bitwise/arithmetic operations on <code>abstract base (aligned to N) + known offset</code> pointer values when it was possible to adjust the offset, i.e. the operation was compatible with the value of <code>N</code>)</p>
</blockquote>
<p>yeah it used to have that. it was a maintenance nightmare. I'm so happy that code is gone. I don't think it's worth it.<br>
(this is the "increasing amount of hacks" I referred to above.)</p>



<a name="245481015"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245481015" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245481015">(Jul 09 2021 at 18:37)</a>:</h4>
<p><span class="user-mention silent" data-user-id="119009">eddyb</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F/near/245477415">said</a>:</p>
<blockquote>
<p>so I'm confused as to what is being suggested. you can totally have an <code>usize</code> that contains an <em>abstract</em> pointer, in CTFE miri, today, AFAIK. it's just not <em>a concrete integer value</em></p>
</blockquote>
<p>yes and it is UB to do that (per the docs that are being added in <a href="https://github.com/rust-lang/rust/issues/85769">#85769</a>). you could not do anyting useful with that <code>usize</code> anyway, <em>any</em> arithmetic operation on it would abort CTFE.</p>



<a name="245481488"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245481488" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245481488">(Jul 09 2021 at 18:40)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F/near/245475642">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="120791">RalfJ</span> Also, no, I'm not asking for an example of the halting problem, I'm specifically asking about cases where we can't prove that the function <em>doesn't</em> do non-deterministic things with pointer values. We are allowed to reject valid programs. So I'm wondering if there's a line we can draw that's practically useful.</p>
</blockquote>
<p>oh I see. hm... you'd basically have to detect when ptr-to-int transmute might happen. It would not be that hard to reject a <code>transmute</code> if it might turn a ptr into an int, though not sure how many reasonable usecases that would kill. However... I think once we have raw ptrs in const, that is basically impossible to do -- any read of a <code>*const usize</code> might actually read a pointer. If we want a sound analysis here, I don't think we can make this analysis accept enough code for this to be useful. If we don't want a sound analysis then it is irrelevant for this discussion IMO.</p>



<a name="245485828"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245485828" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245485828">(Jul 09 2021 at 19:20)</a>:</h4>
<p><span class="user-mention" data-user-id="120791">@RalfJ</span> "public image" might be not quite the right term. Maybe I should have said "understandability".</p>
<p>Essentially, with each edge case the rules become harder to use. Unsafe Rust is already harder to use properly than C in some cases because of how pointers and references interact. We should try our best not to exacerbate things.</p>



<a name="245492191"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245492191" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245492191">(Jul 09 2021 at 20:15)</a>:</h4>
<p><span class="user-mention" data-user-id="120791">@RalfJ</span> So, I feel like that kinda dodges the real question about pointers and non-determinism somewhat.</p>



<a name="245492388"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245492388" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245492388">(Jul 09 2021 at 20:17)</a>:</h4>
<p><span class="user-mention" data-user-id="120791">@RalfJ</span> Playing with the low bits of pointers, or otherwise swizzling and unswizzling pointers, is the kind of trick people reasonably expect to be able to do with a systems programming language; they do it with C and they do it with Rust. If the compiler tries to prevent people from doing that, people are going to start searching for the "stop that" hammer until the compiler relents.</p>



<a name="245492536"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245492536" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245492536">(Jul 09 2021 at 20:18)</a>:</h4>
<p>CTFE is another matter, and if there's a genuine reason why we <em>can't</em> support it there, that'd be unfortunate but <em>might</em> not be a showstopper. But it always needs to remain possible at runtime, and I generally feel that anything we can do at runtime that doesn't depend on runtime inputs should be possible at compile time as well.</p>



<a name="245492691"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245492691" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245492691">(Jul 09 2021 at 20:19)</a>:</h4>
<p>I do appreciate that compilers make provenance a thing, and that we have to cope with that. That may limit the degree to which people can pull even more exotic tricks that might jump from one pointer to a different one, without explicitly informing the compiler about the provenance of the pointer they're using. But provenance shouldn't prevent taking pointer A, reversibly swizzling it, unswizzling it back to pointer A, and dereferencing it, as long as the compiler remembers that it was pointer A with the provenance of pointer A.</p>



<a name="245493133"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245493133" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245493133">(Jul 09 2021 at 20:23)</a>:</h4>
<p><span class="user-mention silent" data-user-id="120791">RalfJ</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F/near/245481488">said</a>:</p>
<blockquote>
<p>However... I think once we have raw ptrs in const, that is basically impossible to do -- any read of a <code>*const usize</code> might actually read a pointer. If we want a sound analysis here, I don't think we can make this analysis accept enough code for this to be useful.</p>
</blockquote>
<p>I'm definitely talking about a sound analysis. Setting aside the current CTFE architecture for a moment, isn't this possible by tracking abstract pointers even when they're stored in ints, and doing symbolic evaluation on them while treating the abstract pointer value as opaque? For a first pass, this could just error out the moment you do something that depends on the value of the pointer other than the bits determined by its alignment; that alone would be enough to handle usage of the low-bits, for instance.</p>



<a name="245493171"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245493171" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245493171">(Jul 09 2021 at 20:23)</a>:</h4>
<p>I <em>think</em> you'd just need "what is this an abstract pointer to" and "what's the current offset from the abstract pointer" to make that work.</p>



<a name="245493262"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245493262" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245493262">(Jul 09 2021 at 20:24)</a>:</h4>
<p><code>struct AbstractPointerInt(AbstractPointer, target_usize)</code></p>



<a name="245493438"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245493438" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245493438">(Jul 09 2021 at 20:26)</a>:</h4>
<p>That would be enough to, for instance, do CTFE involving a hash table that makes use of low pointer bits.</p>



<a name="245536027"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245536027" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245536027">(Jul 10 2021 at 07:42)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F/near/245492388">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="120791">RalfJ</span> Playing with the low bits of pointers, or otherwise swizzling and unswizzling pointers, is the kind of trick people reasonably expect to be able to do with a systems programming language; they do it with C and they do it with Rust. If the compiler tries to prevent people from doing that, people are going to start searching for the "stop that" hammer until the compiler relents.</p>
</blockquote>
<p>I'm not opposed to manipulating the low bits of a pointer. I am just saying that casting the ptr to an int, doing the manipulation there, and casting back, is a <em>horrible</em> API for this purpose. It's a bad API even for runtime code, since it loses provenance (making compiler analyses a lot harder or even impossible). It's even worse for CTFE, since losing provenance there is a deal breaker.</p>
<p>So, I don't want to take away these tricks from anyone. I just want those tricks to be provided with a sane API. Rust has in many cases decided to provide better APIs than C does (this is most apparent around integers: no implicit integer type promotion, no implicit UB on overflow, nice methods to perform checked arithmetic... also leading <code>0</code> does not implicitly mean "octal", and tons of things like that). I am saying Rust should do the same for "low-level pointer tricks". Just because C does it one way, doesn't mean that's the best way to do it.</p>



<a name="245536358"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245536358" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245536358">(Jul 10 2021 at 07:50)</a>:</h4>
<p>The smallest change we could do to the API is to remove int-to-ptr casts, and replace them by</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="k">fn</span> <span class="nf">int_to_ptr</span><span class="p">(</span><span class="n">addr</span>: <span class="kt">usize</span><span class="p">,</span><span class="w"> </span><span class="n">provenance</span>: <span class="o">*</span><span class="k">const</span><span class="w"> </span><span class="n">T</span><span class="p">)</span><span class="w"> </span>-&gt; <span class="o">*</span><span class="k">const</span><span class="w"> </span><span class="n">T</span><span class="w"></span>
</code></pre></div>
<p>which is specified to combine the address of <code>addr</code> with the provenance of <code>provenance</code>, and return the resulting pointer. <span class="user-mention" data-user-id="271719">@Mario Carneiro</span> has been saying all along that that's a much saner way to to int-to-ptr casts, and some colleagues that are formally verifying low-level C code (some hypervisor implementation) used this as a compromise with the engineers: the engineers said we really need ptr-int-casts, the verification people said but those are horrible to verify, and they found that with this API verification people could live fine and the hope is engineers are also okay with it. ;)  (EDIT: turns out what thy do is a lot more subtle than this, oh well)<br>
If I could just make a single breaking change in Rust, I think it would be this.</p>



<a name="245536457"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245536457" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245536457">(Jul 10 2021 at 07:52)</a>:</h4>
<p>For CTFE it's a bit more tricky since we don't have absolute addresses... basically if you use a different provenance than what you started with when casting the ptr to an int, you get nonsense. If you inspect the int, you'll notice it's just the offset from the beginning of the allocation -- like a "relative" address. So I am not sure if that is sufficiently understandable in <span class="user-mention" data-user-id="224471">@Lokathor</span>'s terms. It'd basically mean that <code>ptr as usize</code> works (deterministically) at const-time but has a very different meaning.<br>
I think we might be better off providing more targeted, fully deterministic APIs for the things people need to do on pointers (such as working with the low bits).</p>



<a name="245536592"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/Can%20we%20make%20more%20%60const%20unsafe%60%20now%3F/near/245536592" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/Can.20we.20make.20more.20.60const.20unsafe.60.20now.3F.html#245536592">(Jul 10 2021 at 07:56)</a>:</h4>
<p>However, we have now diverged very far from my original question. we started with determinism in <code>const fn</code>, now we are talking about how to support ptr-int casts in <code>const fn</code>. Lucky enough we have <a href="#narrow/stream/213817-t-lang/topic/Stabilize.20const_fn_transmute.2C.20const_fn_union">another thread</a> in T-lang, so we can continue the original discussion there.^^</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>